As e-mail use has become increasingly widespread, e-mail has increasingly been used to communicate important information, such as, information regarding financial transactions. For example, a user may be informed via e-mail that a bank transaction has occurred. The user will want to know or trust that the e-mail was sent by the bank and therefore that the contents can be trusted. A similar situation exists where an e-mail is sent by a third party, such as on the behalf of another user. For example, an electronic payment system may send an e-mail on behalf of a buyer to a seller. The seller needs to be able to trust the e-mail is from the electronic payment system and can proceed with the sale.
A number of technologies, such as SPF (sender policy framework; RFC 4408), Sender ID (sender identification, RFC 4406), PRA (purported responsible address; RFC 4407), Domain Keys, and Domainkeys identified mail (RFC 4871), have been developed to help verify e-mail exchanged between servers or MTAs (mail transfer agents). Generally, these technologies are used to help ensure that the identifying information included in an e-mail's headers correlates with the sending MTA. However, these technologies do not address the problem of legitimate yet fraudulent senders. For example, an e-mail sent from YourOnlineBank.com (with the number “0”) may comply with all of the necessary standards, but a user receiving that e-mail may easily confuse it for a legitimate e-mail from YourOnlineBank.com (with the letter “0”). Another example, e-mail headers may be spoofed to make it look like the e-mail came from a bank server such as customersupport56@yourbank.com which is not authorized to send e-mail or may not exist.
The existing standards are set up to prevent fraudulent e-mail from reaching an end user. More specifically, the standards executed by e-mail servers. However, the current standards do not protect the user from fraudulent e-mail with seemingly correct, but misleading, header information. Further, the current standards do not test for authenticity or trustworthiness and do not provide the user with any indication that an e-mail is authentic and trustworthy.